1. Field of the Invention
The present invention relates to a computer system and method providing a memory buffer for use with native and platform-independent software code.
2. Description of the Related Art
A common trend among computer specialists is to use safe computer-programming languages and systems to implement computer programs. Typically, programs written in these safe computer-programming languages are compiled to a platform-independent code for execution within safe virtual machines on a variety of target computers. In this context, the term “safe” indicates a level of confidence that the program and runtime system will not interfere with other applications running on the target computer and will not adversely affect memory use.
The growing popularity of these safe computer-programming languages has not, however, obviated the need for using native code on the target computers. Native code is code that has been compiled into the native instruction set of a particular computer processor, and additionally in the context of this document refers to code originally developed in an unsafe language (such as C, C++, or low-level assembler languages). While safe languages offer many benefits, including inherent code reliability, increased programmer productivity, and ease of code maintenance, it is quite often desirable to execute user-supplied native code. There are several reasons for accepting this impurity, such as higher performance, access to devices and programming interfaces for which there is no standard mapping from the platform-independent runtime system, and direct interaction with operating system services. Nevertheless, native code is often unsafe and, as such, may be less reliable than using the safe language.
As an example of how native code may be accessed by safe code running in a safe environment, FIG. 1 illustrates platform-independent runtime environment 104 accessing native code library 106. Platform-independent runtime environment 104 is contained within process 102 and is typically executing a platform-independent program. Process 102 also includes native code library 106 and platform-independent native interface (PINI) 108. Platform-independent runtime environment 104 and any executing platform-independent programs access native code library 106 through PINI 108. The interaction through PINI 108 can have two forms: downcall 110 (when a platform-independent program calls a native sub-routine) and upcall 112 (when a native sub-routine needs to access data or invoke sub-routines of the platform-independent program). In this example, PINI 108 is the only access point to native code library 106 from platform-independent runtime environment 104. In operation, a platform-independent program running in platform-independent runtime environment 104 can make downcall 110 to a sub-routine within native code library 106. In turn, native code library 106 can make an upcall 112 to platform-independent runtime environment 104 to access data and platform-independent sub-routines.
The goal of providing native code that does not violate certain safety policies while it is executing in the same address space as the platform-independent code has been the focus of several research projects. Descriptions of relevant research projects can be found in the following references: Efficient Software Fault Isolation (Wahbe, R., Lucco, S., Anderson, T., and Graham, S., 14th ACM Symposium on Operating Systems Principles, Asheville, N.C. December 1993) describing augmenting native code with safety-enforcing software checks; Safe Kernel Extensions without Runtime Checking (Necula, G., and Lee, P., Proceedings of the Second Symposium on Operating Systems Design and Implementation, Seattle, Wash., 1996) describing statically analyzing native code and proving it to be memory safe; and TALx86: A Realistic Typed Assembly Language (Morrisett, G., Crary, K., Glew, N., Grossman, D., Samuels, K., Smith, F., Walker, D., Weirich, S., and Zdancewic, S., Proceedings of ACM SIGPLAN Workshop on Compiler Support for System Software, Atlanta, Ga., May 1999) describing designing a low-level, statically typed target language for compiling native code.
While the methods used in these research projects have been successful to a point and are useful in some circumstances, their usefulness for addressing problems with an arbitrary native library is rather limited. Augmenting the native code with safety-enforcing software checks can incur a substantial performance penalty, which is difficult to accept when considering that the native code is often used as a performance-boosting mechanism. Statically analyzing the native code and proving that it is safe requires the availability of the source code for the native code and the generation of formal proofs of correctness, which is difficult or otherwise not practical.
In addition to these complexities, certain newer versions of platform-independent environments, such as Java™, now allow for memory sharing between the virtual machine and the native code library. The memory sharing through direct buffers adds further complexity to systems with mixed language programs, including native code.
Accordingly, there is a need for an improved method and system that allows a safe program to use sub-routines in a native code library that may be extended for use with direct buffers.